Nautilus 1992 July/Nautilus-3-8/Nautilus-3-8.bin/Tools & Utilities/Techy Stuff/Doco ƒ/CSMP ƒ/CSMP-V1-053.TXT

Text File | 1992-06-03 | 43.2 KB | 1,197 lines

C.S.M.P. Digest             Sat, 18 Apr 92       Volume 1 : Issue 53

Today's Topics:

    C.S.M.P. Digest Mailing List * Call For Votes *
    where is alpha?
    Think C Debugger...pain in my a$$....
    Fast Event Handling During Calculations (How?)
    AppleLink <-> internet ?
    enum in Think C
    Printer Info Stored Where?
    Problem with FSpExchangeFiles


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.  The last several issues of the digest are available from
sumex-aim.stanford.edu as well.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Michael A. Kelly)
Subject: C.S.M.P. Digest Mailing List * Call For Votes *
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Mon, 9 Mar 1992 02:06:02 GMT


>From:    "Corp. Reed" <[e-mail]>
>
>Would it be possible to get a Comp.sys.mac.programmer digest mailing list
>going?  Some people are still unblessed by the wonders of ftp and news,
>and this would probably be doing them a big favor.
>
>-Corp Reed

It certainly could be done.  What do you all think?

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
[e-mail]                             Computer Science Department
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (Reza A. Tabib-Azar)
Date: 9 Mar 92 04:47:54 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)


In a previous article, [e-mail] (Michael A. Kelly) says:

>
>>From:    "Corp. Reed" <[e-mail]>
>>
>>Would it be possible to get a Comp.sys.mac.programmer digest mailing list
>>going?  Some people are still unblessed by the wonders of ftp and news,
>>and this would probably be doing them a big favor.
>>
>>-Corp Reed
>
>It certainly could be done.  What do you all think?
>
>Mike.
>--
>_____________________________________________________________________________
>Michael A. Kelly                                         University of Oregon
>[e-mail]                             Computer Science Department
>_____________________________________________________________________________
>
Agreed, it would be very nice.

Reza A. Tabib-Azar
EBME CWRU

+++++++++++++++++++++++++++

From: [e-mail] (Edwin Howell Watkeys III)
Date: 9 Mar 92 04:43:39 GMT
Organization: Drexel University (Comp Sci) / Distant Software


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Michael A. Kelly) writes:
> >From:    "Corp. Reed" <[e-mail]>
> >
> >Would it be possible to get a Comp.sys.mac.programmer digest mailing list
> >going?  Some people are still unblessed by the wonders of ftp and news,
> >and this would probably be doing them a big favor.
> >
> >-Corp Reed
>
> It certainly could be done.  What do you all think?
>
> Mike.
>

I get news, but I think it would be nice to get a "noise-free" distillation
of comp.sys.mac.programmer... In other words, "yes."

Ed

- ---------
Ed Watkeys                         "...the peace symbol is actually an an-
phlpa!caligula![e-mail]   cient Druidic symbol which means 'de-
Programmer, Athiest, Cynic          feat Christianity.'" -- P. Hoefflinger
Distant Software/Drexel University  ------CYNICAL QUOTE OF THE WEEK-------

+++++++++++++++++++++++++++

From: [e-mail] (Robert Bruce Findler)
Date: 9 Mar 92 17:50:04 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA

Good idea. I would like to be on the list.

.................................................................
:    [e-mail]    : The fan awaits the shit, Madame. :
: [e-mail] : Moliere's, _The Misanthrope_     :
:............................:...............................ECFO

+++++++++++++++++++++++++++

From: [e-mail] (The Weasel)
Organization: DSG, Stanford University, CA 94305, USA
Date: Wed, 11 Mar 92 06:41:05 GMT

Count me as an aye vote.

Peter

+++++++++++++++++++++++++++

From: [e-mail]
Date: 10 Mar 92 15:43:20 GMT
Organization: BC Systems Corporation

In article <[e-mail]>, [e-mail] (Michael A. Kelly) writes:
>
>>From:    "Corp. Reed" <[e-mail]>
>>
>>Would it be possible to get a Comp.sys.mac.programmer digest mailing list
>>going?  Some people are still unblessed by the wonders of ftp and news,
>>and this would probably be doing them a big favor.
>>
>>-Corp Reed
>
> It certainly could be done.  What do you all think?

I like it and would like each digest e-mailed to me!!!! I like I like I
like!!!!

address below
- --
[e-mail]
Victoria, British Columbia, Canada

+++++++++++++++++++++++++++

From: [e-mail] (Peter Creath)
Date: Wed, 11 Mar 92 20:00:39 CST
Organization: Cube Technologies

I vote for a mailing list...

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]   become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Andrew E Page)
Organization: The World Public Access UNIX, Brookline, MA
Date: Mon, 16 Mar 1992 18:07:38 GMT

  I VOTE YES.  and I would probably set asside a separate area on my
hard disk for the digest, and a macro key in White Knight to download
it from my mail once it dropped in.


- --
Andrew E. Page CTO(Warrior Poet)|   Decision and Effort The Archer and Arrow
DSP Ironworks                   |     The difference between what we are
Macintosh and DSP Technology    |           and what we want to be.

+++++++++++++++++++++++++++

From: [e-mail] (Kent P Miller)
Organization: Engineering Computer Network, University of Oklahoma, Norman, OK
Date: Tue, 17 Mar 1992 17:42:44 GMT

In article <[e-mail]> [e-mail] (Andrew E Page) writes:
>  I VOTE YES.  and I would probably set asside a separate area on my
>hard disk for the digest, and a macro key in White Knight to download
>it from my mail once it dropped in.
>

At the risk of flooding someone's ftp site - somebody is keeping a digest
already and has been for a while.  If everyone would like to take a look,
they are for anonymous ftp from

skinner.cs.uoregon.edu

in the directory (I think) pub/mac/csmp-digest.  From what I can tell, the
person compiling them is doing a very good job.  He's done about 20 issues
so far.
- --
- -----------------------
Kent Miller
[e-mail]
- -----------------------

---------------------------

From: [e-mail] (Joseph A Casella)
Subject: where is alpha?
Organization: The Ohio State University
Date: Mon, 16 Mar 1992 13:48:18 GMT


I recently downloaded a copy of harvest c, and the author recommended
that a shareware text editor called "alpha" be used with it.

I checket the major ftp sites (sumex, rascal, umich) and have been
unable to find a copy of alpha or anything else that looked like a
text editor.  Can anybody tell me where I can find "alpha" or
something like it?


+++++++++++++++++++++++++++

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 16 Mar 1992 15:29:34 GMT

In <[e-mail]> [e-mail] (Joseph A Casella) writes:

>I recently downloaded a copy of harvest c, and the author recommended
>that a shareware text editor called "alpha" be used with it.

>I checket the major ftp sites (sumex, rascal, umich) and have been
>unable to find a copy of alpha or anything else that looked like a
>text editor.  Can anybody tell me where I can find "alpha" or
>something like it?
[there is nothing like Alpha]

Look again.  Behold, mac.archive.umich.edu :

ftp> pwd
257 "/mac/utilities/editors" is current directory.

ftp> dir
200 PORT command successful.
150 Opening data connection for /bin/ls (129.229.1.100,2270) (0 bytes).
total 1211
drwxrwxr-x  2 20020    staff        2048 Dec 31 15:40 .AppleDouble
- -rw-rw-r--  1 20062    staff      272420 Oct 26 20:25 alpha4.01.cpt.hqx
                                                      ^^^^^^^^^^^^^^^^^
If you have a DeskWriter or StyleWriter, the current version of Alpha
won't print for you.  Mail to [e-mail] and he will mercifully
help you.

Caveat: what version of Harvest C did you get ?  I assume you got version
1.1, or more accurately 1.1b2.  If you just want to see the compiler to
take a look at it, look at that one, but it's pretty buggy still.  The
new version is much better, really.  Look on harvest.cecer.army.mil,
in pub/mac/harvestc/pretest.hqx.  This is version 1.2d1.  It's not even
alpha-test quality yet, but I'd speculate it might be more stable than
1.1b2.  I'm currently doing pre-alpha testing, and will start alpha test
asap.  I hope to have a 1.2 final by June 17 at the latest.  Anyway, if
you want to really use the compiler, you'll save yourself some frustration
if you wait a little bit...

- --
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

---------------------------

From: [e-mail]
Subject: Think C Debugger...pain in my a$$....
Date: 12 Mar 92 00:17:16 EST
Organization: Univ of Miami IR

Grrrrrr....

I just spent all f***ing day trying to find out why I couldn't use
the debugger from TC5.0.2 on my project (it kept saying "out of memory")
so after rewriting some utilities to remove ANSI and then a whole host of other
things..on a whim I coppied my files from the file server to the local hard
drive....bam...it works fine.....OH CHRIST!!!!!
Well I'm calm now but I thought appleshare was supposed to be transparent...
Ahh well I guess someone did something funky somewhere...
Peace...
- --
Ian Sullivan
*******************************************************************************
**[e-mail]      %   "Friendly Fire"..There is no such thing   **
**[e-mail]      %    Remember your gun was made by the        **
**[e-mail]            %    lowest bidder.                           **
**[e-mail]      %   "A question to god...                     **
**                             %       Jason Gross....why?"-a poem           **
**UUU    UMUMMM     MMMMMM     %                                             **
**UUU    UMU MMM   MMM MMM     %   "Skate to Kill--Kill to Skate"            **
**uUU    UMU  MMM MMM  MMM     %   "Life's been good to me so far..." -J.W.  **
**UUUUUUUUMUof MMMMM   MMM     %   "Give it a while." -Me.                   **
*******************************************************************************
Yes..yes...I know I spelled it wrong......whatever it was. ;)

+++++++++++++++++++++++++++

From: [e-mail] (Joe Zobkiw)
Date: 13 Mar 92 17:29:19 GMT
Organization: The World Public Access UNIX, Brookline, MA

Um...just a suggestion...don't ever run any files from a file server...
especially if you're programming! What if the server crashed? You might go
with it!


- --
<--------------------------------------------------->
 joe zobkiw                     [e-mail]
 mac.synthesis.MIDI.development.C.asm.communications
>---------------------------------------------------<

+++++++++++++++++++++++++++

From: [e-mail] (Ray Fischer)
Organization: Computer Science Department, Stanford University.
Date: Sun, 15 Mar 1992 00:07:53 GMT

[e-mail] writes ...
>I just spent all f***ing day trying to find out why I couldn't use
>the debugger from TC5.0.2 on my project (it kept saying "out of memory")
>so after rewriting some utilities to remove ANSI and then a whole host of other
>things..on a whim I coppied my files from the file server to the local hard
>drive....bam...it works fine.....OH CHRIST!!!!!

An easier solution would have been to reduce the memory partition for
the application or Think C, or turn on virtual memory.  I'll agree
that the message in unnecessarily cryptic, but it _is_ explained
in the manual.  You get the message when Think C + Debugger + Application
is greater than the amount of free memory.

>Well I'm calm now but I thought appleshare was supposed to be transparent...

But it does use up memory.

Ray
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Sun, 15 Mar 1992 14:03:32 GMT

>>>>> On Sun, 15 Mar 1992 00:07:53 GMT, [e-mail] (Ray Fischer) said:

 > [e-mail] writes ...
>>Well I'm calm now but I thought appleshare was supposed to be
>>transparent...

 > But it does use up memory.

The problem that Ian was running into doesn't have anything to do with
memory. If you try to use the THINK C debugger when the THINK C app
and the Debugger are on an AppleShare server, you'll get an "Out of
Memory" error when THINK C tries to lauch the debugger. THINK C 5.0 is
not intended to run off of an AppleShare server; this may be changed
in a future release, but for now that's the way it is.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Robert Minich)
Date: 15 Mar 92 22:43:01 GMT
Organization: Oklahoma State University

by [e-mail] (Phil Shapiro):
> The problem that Ian was running into doesn't have anything to do with
> memory. If you try to use the THINK C debugger when the THINK C app
> and the Debugger are on an AppleShare server, you'll get an "Out of
> Memory" error when THINK C tries to lauch the debugger. THINK C 5.0 is
> not intended to run off of an AppleShare server; this may be changed
> in a future release, but for now that's the way it is.

What on earth does ThC do that breaks it on a file server?

- --
Robert Minich
[e-mail]   |Godwin's Rule of Nazi Analogies: As a Usenet dis-
Oklahoma State University |cussion grows longer, the probability of a com-
Bill 'n Opus for '92      |parison involving Nazis or Hitler approaches one.

+++++++++++++++++++++++++++

From: [e-mail] (Steve Poole)
Organization: Walker Richer & Quinn
Date: Mon, 16 Mar 1992 20:25:41 GMT

In article <[e-mail]>, [e-mail] (Phil Shapiro) writes:
>
> The problem that Ian was running into doesn't have anything to do with
> memory. If you try to use the THINK C debugger when the THINK C app
> and the Debugger are on an AppleShare server, you'll get an "Out of
> Memory" error when THINK C tries to lauch the debugger. THINK C 5.0 is
> not intended to run off of an AppleShare server; this may be changed
> in a future release, but for now that's the way it is.

Hmm.  I'm running into the same thing.  However, my ThC stuff is
local, the project is on the server, and I have over 10M free for
the debugger and debugged app (together wanting 600K + 512K).  If
I turn off Use Debugger it runs, otherwise "out of memory" pops up.
Didn't happen until I put it on the server, and if I move the
project local again it's OK.  This is 5.0.2.  Any ideas?

- --------------------------------------------------------------------------
- -- INTEL 80x86: Just say NOP -- Internet: [e-mail] -- AOL: Spoole --
- --------------------------------------------------------------------------



+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Tue, 17 Mar 1992 14:43:07 GMT

>>>>> On 16 Mar 92 20:25:41 GMT, [e-mail] (Steve Poole) said:
 > In article <[e-mail]>, [e-mail] (Phil Shapiro) writes:

>> The problem that Ian was running into doesn't have anything to do
>> with memory. If you try to use the THINK C debugger when the THINK
>> C app and the Debugger are on an AppleShare server, you'll get an
>> "Out of Memory" error when THINK C tries to lauch the debugger.

 > Hmm.  I'm running into the same thing.  However, my ThC stuff is
 > local, the project is on the server, and I have over 10M free for
 > the debugger and debugged app (together wanting 600K + 512K).  If I
 > turn off Use Debugger it runs, otherwise "out of memory" pops up.

As it turns out, THINK C uses the same technique to "launch" your
project as it does to launch the debugger. It kind of fools the OS
into thinking that your project is temporarily a launchable
application. So, the two errors are caused by the same problem.

The "Out Of Memory" error is probably just the OS error that we happen
to get back from _Launch. I have no idea how this part of THINK C
works, so I don't really know why it doesn't work correctly.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Captain Kludge)
Organization: Purdue University Engineering Computer Network
Date: 17 Mar 92 16:14:30 GMT




>In article <[e-mail]>, [e-mail] (Phil Shapiro) writes:
>>
>> The problem that Ian was running into doesn't have anything to do with
>> memory. If you try to use the THINK C debugger when the THINK C app
>> and the Debugger are on an AppleShare server, you'll get an "Out of
>> Memory" error when THINK C tries to lauch the debugger. THINK C 5.0 is
>> not intended to run off of an AppleShare server; this may be changed
>> in a future release, but for now that's the way it is.

>Hmm.  I'm running into the same thing.  However, my ThC stuff is
>local, the project is on the server, and I have over 10M free for
>the debugger and debugged app (together wanting 600K + 512K).  If
>I turn off Use Debugger it runs, otherwise "out of memory" pops up.
>Didn't happen until I put it on the server, and if I move the
>project local again it's OK.  This is 5.0.2.  Any ideas?


Yes,
  The problem is that the project has to be local.  The application
  and debugger can be on a server, I have done this and it works fine.
  This is 5.0.2 also.

- -John


---------------------------

From: [e-mail] (Roger Allen)
Subject: Fast Event Handling During Calculations (How?)
Date: 12 Mar 92 18:45:25 GMT
Organization: Amdahl Corporation, Sunnyvale CA

What is the best way to do some sort of calculation that will take some
time WITHOUT making the calculation time much longer due to adding code
do deal with the following.
  1) get events (like clicking a 'Cancel' button).
  2) allow your program to be put into the background.
  3) allow other programs to receive events.

I have some calculations that I must do and I want to please both the
people who want fast calculation time and also the people who want to
run it in the background and do word processing or something else.

Psuedocode:
   bring up progress dialog box
   while not done do {
     do calculation and store value
     update dialog box
     if event (HELP this takes alot of time!)
       do event
   }
   bring down progress dialog box

I've tried a few things for the "if event" part and all slow down
my code ALOT.  I'm doing about 20K calculations or more. (all floating pt)
Calculation time goes from ~10sec to ~20sec with event handling.

Any help is appreciated.

Roger.
- --
> Roger Allen                   |  All the opinions expressed are my     <
> Amdahl Computer Development   |  own and are not Amdahl's.             <
> [e-mail]           |  ------They paid me to say that------- <

+++++++++++++++++++++++++++

From: [e-mail] (Sven Grenander)
Organization: Jet Propulsion Laboratory
Date: Thu, 12 Mar 1992 21:24:20 GMT

In article <[e-mail]>, [e-mail] (Roger Allen) writes:
>
> What is the best way to do some sort of calculation that will take some
> time WITHOUT making the calculation time much longer due to adding code
> ....


The way I handle this is either of the following (depending on
how long the operation is likely to take):

If it is a long operation which does not have to be finished
right away (write multi-meg files with sorting interspersed, or
some such thing) I simply post a chore (ThC CChore) to trigger
X executions every time through the event loop.

If it is a higher priority, shorter duration activity I simply
put an EventAvail in the tight loops. If the EventAvail == TRUE
I save my current loop variables, post a chore to re-enter
the loop, exit out to the main event loop and pick back up
where I was in the loop when the chore fires again.

This second method works very well for me, actually both do.
However, the second one lets me accept a 19.2 Kb serial feed,
with rather messy parsing, window updating and Object creation,
disposal etc while not impacting word processing, MacDrawing
or whatever. At least I can't type fast enough to outrun my fx.

Good luck.

- -Sven


+++++++++++++++++++++++++++

From: [e-mail] (Don Berry)
Date: 12 Mar 92 22:27:47 GMT
Organization: University of Pennsylvania

In article <[e-mail]>, [e-mail]
    (Roger Allen) writes:
>
> What is the best way to do some sort of calculation that will take some
> time WITHOUT making the calculation time much longer due to adding code
> do deal with the following.
>   1) get events (like clicking a 'Cancel' button).
>   2) allow your program to be put into the background.
>   3) allow other programs to receive events.

Although I suppose it's not that graceful, I just handle events on
every nth pass through the calculation loop, where n can be adjusted
to meet your performance objectives. For example, in a routine that
reads text lines, parses, and writes the result, I check for events
every 50-100 lines and it seems to be reasonably well behaved in background.
 (Oh yeah, WaitTicks = 20L).

modification of Roger's pseudo-code:

   while not done do {
     do calculation and store value
     update dialog box
     if (i%100 == 0)
       check for event and deal with it
     i++;
   }

I'd be delighted in any of you serious programmers out there would
(a) comment on the potential evils of this method and (b) suggest
more elegant methods.

Don Berry
Department of Chemistry
University of Pennsylvania



+++++++++++++++++++++++++++

From: [e-mail] (David Swofford )
Organization: University of Illinois at Urbana
Date: Thu, 12 Mar 1992 22:48:06 GMT

[e-mail] (Sven Grenander) writes:

>In article <[e-mail]>, [e-mail] (Roger Allen) writes:
>>
>> What is the best way to do some sort of calculation that will take some
>> time WITHOUT making the calculation time much longer due to adding code
>> ....

>The way I handle this is either of the following (depending on
>how long the operation is likely to take):

>If it is a long operation which does not have to be finished
>right away (write multi-meg files with sorting interspersed, or
>some such thing) I simply post a chore (ThC CChore) to trigger
>X executions every time through the event loop.

>If it is a higher priority, shorter duration activity I simply
>put an EventAvail in the tight loops. If the EventAvail == TRUE
>I save my current loop variables, post a chore to re-enter
>the loop, exit out to the main event loop and pick back up
>where I was in the loop when the chore fires again.

>This second method works very well for me, actually both do.
>However, the second one lets me accept a 19.2 Kb serial feed,
>with rather messy parsing, window updating and Object creation,
>disposal etc while not impacting word processing, MacDrawing
>or whatever. At least I can't type fast enough to outrun my fx.

This may have missed the point of the original poster's question
(apologies to Sven if I'm wrong).  My application also does
heavy-duty computation for long periods, but I want to watch for
update, suspend/resume, etc. events (and most importantly, command-period
keyboard events).  I suspect the original poster had the same thing
in mind.  Calling GetNextEvent or WaitNextEvent from computation loops
can REALLY slow things down a lot.  I used to call EventAvail
(actually OSEventAvail, which is even faster) and didn't call
Get/WaitNextEvent unless I knew there was an event to deal with.
But this approach didn't work well with MultiFinder, so I decided
on the following:

If you're in the FOREGROUND, call Get/WaitNextEvent only twice a second
or so.  I just keep a 'lastEventCheckTime' after every such call and
do an "if (Ticks - lastEventCheckTime > 30)" test before checking for
events and processing them.  The worst that can happen is that there
will be a slight delay (no more than 1/2 a second) after a user
hits a command-period key (or whatever) until the event gets handled.
I find that event-checking has little impact on the speed of the
calculations as long as you limit it to this rate.  But if you're in
the BACKGROUND, it's crucial to call GetNextEvent or (preferably)
WaitNextEvent much more often, so that you won't slow the foreground
application to a crawl (It doesn't do any good to allow background
calculations if you impose a 1/2 sec delay on every keystroke on the
foreground app).
- --
David L. Swofford                 Phone:    [phone]
Illinois Natural History Survey   FAX:      [phone]
607 E. Peabody Drive              BITNET:   DAVESWOF@UIUCVMD
Champaign, Illinois 61820 USA     Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 13 Mar 92 16:45:44 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.com> [e-mail] (Roger Allen) writes:

   Psuedocode:
      bring up progress dialog box
      while not done do {
    do calculation and store value
    update dialog box
    if event (HELP this takes alot of time!)
      do event
      }
      bring down progress dialog box

You could do one of the following:

    cnt = 0 ;
    bring up progress dialog
    while not done do {
        calculate
        if ( inBackground || ! ( cnt++ & 0xf ) ) {
            updateprogress
            eventhandling
        }
    }

Note: inBackground is changed by eventhandling according to
suspend/resume events.

eventhandling should pass 0 to WaitNextEvent, and probably a
NULL mouseRgn. The beauty of this is that the user who wants
to get the result will look at the progess bas in the foreground,
and only gets his event every 16 passes, while the backgrounding
user will get good background time (you should pass 10 for the
waitnextevent time in the background, and 0 in the foreground)

You could be tempted to change the !(cnt++&0xf) part to something
like TickCount()>nextTime, but that gives a trap dispatch while
in te foreground... DO NOT USE "Ticks" AS IT'S UNAVAILABLE UNDER A/UX
and also may very well be optimized away by your compiler.
Code like:

    while ( Ticks < contTime ) ;

Has been known to hang, because the compiler regards Ticks as a
variable that does not change inside the loop...

- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 14 Mar 92 04:49:06 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Roger Allen) writes:

>What is the best way to do some sort of calculation that will take some
>time WITHOUT making the calculation time much longer due to adding code
>do deal with [events and letting other programs have time]

>I have some calculations that I must do and I want to please both the
>people who want fast calculation time and also the people who want to
>run it in the background and do word processing or something else.

>Psuedocode:
>   bring up progress dialog box
>   while not done do {
>     do calculation and store value
>     update dialog box
>     if event (HELP this takes alot of time!)
>       do event
>   }
>   bring down progress dialog box

>I've tried a few things for the "if event" part and all slow down
>my code ALOT.  I'm doing about 20K calculations or more. (all floating pt)
>Calculation time goes from ~10sec to ~20sec with event handling.

How about breaking the event handling into two pieces: when your app is in the
foreground and when it's in the background.  In the foreground case, you'll
probably want to run as fast as possible since the user's sitting there
waiting.  In the background case, they're doing something else, so you can
yield more time to the other apps they're probably playing with.

Replace the "if event" pseudocode with:

if (not in foreground) or (yieldTicks < TickCount) or (EventAvail()) {
  do event
  yieldTicks = TickCount() + HoldoffTicks
}


You need to initialize yieldTicks=0.  EventAvail() is a system routine that
will check if there are any pending events.  This should allow you to quickly
respond to events without yielding all the time, yet let other apps in once
in awhile.  Note that I'm not sure if any process stuff has been patched into
EventAvail for system 7.0, so you may still be hosed...

steve
- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

+++++++++++++++++++++++++++

From: [e-mail] (David Swofford)
Date: 13 Mar 92 04:48:06 GMT
Organization: Macnet Omaha

(From: [e-mail] (David Swofford ))
(Organization: University of Illinois at Urbana)

[e-mail] (Sven Grenander) writes:

>In article <[e-mail]>, [e-mail]
(Roger Allen) writes:
>>
>> What is the best way to do some sort of calculation that will take some
>> time WITHOUT making the calculation time much longer due to adding code
>> ....

>The way I handle this is either of the following (depending on
>how long the operation is likely to take):

>If it is a long operation which does not have to be finished
>right away (write multi-meg files with sorting interspersed, or
>some such thing) I simply post a chore (ThC CChore) to trigger
>X executions every time through the event loop.

>If it is a higher priority, shorter duration activity I simply
>put an EventAvail in the tight loops. If the EventAvail == TRUE
>I save my current loop variables, post a chore to re-enter
>the loop, exit out to the main event loop and pick back up
>where I was in the loop when the chore fires again.

>This second method works very well for me, actually both do.
>However, the second one lets me accept a 19.2 Kb serial feed,
>with rather messy parsing, window updating and Object creation,
>disposal etc while not impacting word processing, MacDrawing
>or whatever. At least I can't type fast enough to outrun my fx.

This may have missed the point of the original poster's question
(apologies to Sven if I'm wrong).  My application also does
heavy-duty computation for long periods, but I want to watch for
update, suspend/resume, etc. events (and most importantly, command-period
keyboard events).  I suspect the original poster had the same thing
in mind.  Calling GetNextEvent or WaitNextEvent from computation loops
can REALLY slow things down a lot.  I used to call EventAvail
(actually OSEventAvail, which is even faster) and didn't call
Get/WaitNextEvent unless I knew there was an event to deal with.
But this approach didn't work well with MultiFinder, so I decided
on the following:

If you're in the FOREGROUND, call Get/WaitNextEvent only twice a second
or so.  I just keep a 'lastEventCheckTime' after every such call and
do an "if (Ticks - lastEventCheckTime > 30)" test before checking for
events and processing them.  The worst that can happen is that there
will be a slight delay (no more than 1/2 a second) after a user
hits a command-period key (or whatever) until the event gets handled.
I find that event-checking has little impact on the speed of the
calculations as long as you limit it to this rate.  But if you're in
the BACKGROUND, it's crucial to call GetNextEvent or (preferably)
WaitNextEvent much more often, so that you won't slow the foreground
application to a crawl (It doesn't do any good to allow background
calculations if you impose a 1/2 sec delay on every keystroke on the
foreground app).
- --
David L. Swofford                 Phone:    [phone]
Illinois Natural History Survey   FAX:      [phone]
607 E. Peabody Drive              BITNET:   DAVESWOF@UIUCVMD
Champaign, Illinois 61820 USA     Internet: [e-mail]

- ---
 * Origin: Interuniverse Gateway (ivgate), Omaha (11:30102/2.0)
SEEN-BY: 285/1 285/14

+++++++++++++++++++++++++++

From: [e-mail] (Anders Sundin)
Date: 16 Mar 92 11:30:26 GMT
Organization: Organic Chemistry 2, Lund University, Sweden

Roger Allen writes:
>
>   Psuedocode:
>      bring up progress dialog box
>      while not done do {
>        do calculation and store value
>        update dialog box
>        if event (HELP this takes alot of time!)
>          do event
>      }
>      bring down progress dialog box
>

In my opinion one should call WaitNextEvent/GetNextEvent at least
ten to twenty times per second. However, when the application is
running in the foreground it is probably enough with two to five
calls per second.

If you tune the loop to a Macintosh Quadra you will get very bad
interactivity on a Macintosh Plus. On the other hand, if you tune
the loop to a Plus you will waste time on a Quadra.

If you want to run well on everything from a Macintosh Plus to a
Quadra you will have to know the real time. You can get this
by calling TickCount after each calculation step. Try to make one
calculation step take about one tick on a Plus to avoid wasting
time by calling TickCount too often.
- --
 Anders Sundin           e-mail: [e-mail]
 Organic Chemistry 2             [e-mail]
 University of Lund              [e-mail]
 P.O. Box 124                    [e-mail]
 S-22100 Lund            phone:  [phone]
 Sweden                  fax:    [phone]

---------------------------

From: [e-mail] (Lars Petrus)
Subject: AppleLink <-> internet ?
Date: 14 Mar 92 20:04:24 GMT
Organization: Stacken Computer Club, Stockholm, Sweden


   This may be a FAQ. It may even be the wrong newsgroup. But at least it's
simple:

How do you send email between here and AppleLink?
Is there any problem with such traffic?


"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 14 Mar 92 22:28:53 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.se> [e-mail] (Lars Petrus) writes:

   How do you send email between here and AppleLink?
   Is there any problem with such traffic?


Well, yes and no:

The problem is that the applelink account pays for both incoming
and outgoing mail, I believe the charge is $0.50 per message
through the gateway.

To mail to someone on AppleLink, for instance nordic ADT, you
mail: [e-mail]

I don't know what it looks like on the other side, but replying
works.

- --
This signature is placed into the Public Domain by Jon W{tte ([e-mail])
                     - The worlds only romantic cynic -

+++++++++++++++++++++++++++

From: [e-mail] (Jan-Erik M}ngs)
Date: 16 Mar 92 12:30:42 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Jon W{tte) writes:

   .se> [e-mail] (Lars Petrus) writes:

      How do you send email between here and AppleLink?

   To mail to someone on AppleLink, for instance nordic ADT, you
   mail: [e-mail]

   I don't know what it looks like on the other side, but replying
   works.

While on AppleLink, send to: [e-mail]@INTERNET#
                             [e-mail]@INTERNET#

---------------------------

From: [e-mail] (Roger H. Kou)
Subject: enum in Think C
Date: 15 Mar 1992 11:40:02 -0800
Organization: USC Computing Services, Los Angeles


hi there,

I have been porting some codes from UNIX to MacOS, using Think C
5.0.2(?) to compile. but I am having trouble w/enum stuff. Can't find
any ref. in the manual.

can someone please give me some insight to this?

thanks,

Roger...

+++++++++++++++++++++++++++

From: [e-mail] (Koichi FUNAKUBO)
Date: 17 Mar 92 01:58:24 GMT
Organization: Information Processing Center, Saga University, Saga, Japan.


  Have you turn on the "enums are always ints" option in the
  Language Settiong page of the Options... dialog ?

  THINK C always makes an enum as small as possible or as large as
  necessary. So you need to turn the option on to port ANSI-conformant
  codes to THINK C.
  These are written on pp.176-177 of the user manual.
- --
                                           =================================
                                             Koichi Funakubo
                                             Department of Physics
                                             Saga University, Saga 840
                                             JAPAN
                                             [e-mail]
                                           =================================

---------------------------

From: [e-mail] (Michael Peterson)
Subject: Printer Info Stored Where?
Date: 15 Mar 1992 18:06:28 -0800
Organization: University of Southern California, Los Angeles, CA



Anyone know where the print info is stored in the system and what it means.
I interested in having some software that sets the print up without using the
chooser.

    Thanks.
    Michael L. Peterson
    [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Benjamin T Sander)
Organization: University of Illinois at Urbana
Date: Tue, 17 Mar 1992 15:31:00 GMT

[e-mail] (Michael Peterson) writes:



>Anyone know where the print info is stored in the system and what it means.
>I interested in having some software that sets the print up without using the
>chooser.

>    Thanks.
>    Michael L. Peterson
>     [e-mail]


Take a look at the 'STR ' resource with id -8192 in the System file.  This
gives the name of the printer TYPE which is selected plus some other
info.

Also, the name of the printer which is currently selected ("ImageWriter 1" or
"ImageWriter II") is stored in the printer driver itself in a PAPA resource.

Ben
bts39313.uxa.uiuc.edu


---------------------------

From: [e-mail] (Richard Beecher)
Subject: Problem with FSpExchangeFiles
Date: 16 Mar 92 21:49:22 GMT
Organization: Arco Alaska, Inc.

I have implemented a "safe save" strategy in my code as suggested in IM VI
using the FSpExchangeFiles function.  Works like a charm, except that the
temporary file that is created in the process doesn't get deleted.  FSpDelete()
returns a file busy error (-47).  The end result is that the temporary file
ends up in the Trash after each restart/reboot.

Incidentally, I can delete the file BEFORE calling FSpExchangeFiles, which
makes me think that FSpExchangeFiles opens the data and/or resource forks, but
does not close them.  Am I right?  If so, what can I do to fix the problem?
Any help would be much appreciated.  Please e-mail to me, and I'll post a
summary.


Richard Beecher
([e-mail])


My code is given below (some portions removed for brevity).


/****************** SaveSettings *****************/

void SaveSettings()
{
   short        foundVRefNum;
   long         foundDirID;
   OSErr        err;
   FSSpec       tempFile;
   short        tempRefNum;
   Str255       tempFileName = { "\pFP Scrap" };


   /* Create a temporary file for the safe save */

   err = FindFolder( kOnSystemDisk, kTemporaryFolderType, kCreateFolder,
                   &foundVRefNum, &foundDirID );
   if ( err )
      ErrorString( "\pCould not find/create the Temporary Items Folder.",
      stopError );
   FSMakeFSSpec( foundVRefNum, foundDirID, tempFileName, &tempFile );

   FSpCreateResFile( &tempFile, 'trsh', 'trsh', smSystemScript );
   err = ResError();
   if ( err )
      ErrorString( "\pCouldn't create the temporary save file!", stopError );

   tempRefNum = FSpOpenResFile( &tempFile, fsRdWrPerm );
   err = ResError();
   if ( err != noErr )
      ErrorString( "\pCouldn't open the temporary save file!", stopError );


   /* Add the resources to the temporary file */

   UseResFile( tempRefNum );
   SaveResources();
   CloseResFile( tempRefNum );


   /* Now, exchange the files */

   /* err = FSpDelete( &tempFile );  <---- works fine here */

   /* Note:  settingsFile already exists */

   err = FSpExchangeFiles( &tempFile, &settingsFile );
   if ( err )
      ErrorString( "\pCouldn't finish the save operation!", stopError );

   err = FSpDelete( &tempFile );  /* returns a file busy error -47 */
   if ( err )
      ErrorString( "\pCouldn't delete the temporary file!", stopError );
}

+++++++++++++++++++++++++++

From: [e-mail] (Richard Beecher)
Date: 17 Mar 92 17:01:18 GMT
Organization: Arco Alaska, Inc.

In article <[e-mail]> I wrote:

>I have implemented a "safe save" strategy in my code as suggested in IM VI
>using the FSpExchangeFiles function.  Works like a charm, except that the
>temporary file that is created in the process doesn't get deleted.
FSpDelete()
>returns a file busy error (-47).  The end result is that the temporary file
>ends up in the Trash after each restart/reboot.
>
>Incidentally, I can delete the file BEFORE calling FSpExchangeFiles, which
>makes me think that FSpExchangeFiles opens the data and/or resource forks, but
>does not close them.  Am I right?  If so, what can I do to fix the problem?

As it turns out, I needed to close both the temporary file AND the settings
file before calling FSpExchangeFiles and FSpDelete, even though I was only
deleting the temporary file.  Many thanks to Jon Watte for the advice!

Richard Beecher ([e-mail])

---------------------------

End of C.S.M.P. Digest
**********************